'MacroExpansionDecl' and 'MacroExpansionExpr' have many common methods.
Introduce a common base class 'FreestandingMacroExpansion' that holds
'MacroExpansionInfo'.

Factor out common expansion logic to 'evaluateFreestandingMacro'
function that resembles 'evaluateAttachedMacro'.

(cherry picked from commit 86d405b)

Expand macros in the specified source file syntactically (without any
module imports, nor typechecking).

Request would look like:
```
{
  key.compilerargs: [...]
  key.sourcefile: <file name>
  key.sourcetext: <source text> (optional)
  key.expansions: [<expansion specifier>...]
}
```
`key.compilerargs` are used for getting plugins search paths. If
`key.sourcetext` is not specified, it's loaded from the file system.
Each `<expansion sepecifier>` is
```
{
  key.offset: <offset>
  key.modulename: <plugin module name>
  key.typename: <macro typename>
  key.macro_roles: [<macro role UID>...]
}
```
Clients have to provide the module and type names because that's
semantic.

Response is a `CategorizedEdits` just like (semantic) "ExpandMacro"
refactoring. Each edit object has `key.buffer_name` that can be used for
recursive expansion. If the client founds nested macro expansion in the
expanded source, it can send another request with the same compiler
arguments using the buffer name and the source to get the nested
expansions.

(cherry picked from commit 43908fad02e4bfe33c6ce61422e820bf82dca6de)

(cherry picked from commit 0c931e063ad2acab6178ea8fbd6c5c525be51166)

(cherry picked from commit 645624129219769fd70301c83b88c14cf18418ad)

(cherry picked from commit 1a4a72aa5fb56e6f31fda56943eb4bc77cd69e72)

(cherry picked from commit 5877c90e6f0d2614b1a9f47f03cb3ad99b0baa5d)

This doesn't support nested expansions for now. So there is not much to
reuse.

(cherry picked from commit 42435995c80a102035e394bc027f2a542d00a0b7)

(cherry picked from commit de41f455493fcfee5c318f74b31bedd5ddeff25e)